Conversation
|
rustbot has assigned @JonathanBrouwer. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Cc'ing some ARM folks (strangely does not seem to exist as a github group, making it hard to ping): |
This comment has been minimized.
This comment has been minimized.
|
Are there any precedent for out-right removing a flag? I see that we have options where we set a special flag that keep the flag, probably to not break people who set it, but still outputs a warning to tell them it does nothing. rust/compiler/rustc_session/src/options.rs Lines 2059 to 2062 in e220d28 |
|
I guess that would also work. Not sure if it's better to silently ignore the flag vs show an error. |
|
I think it still warns. rust/compiler/rustc_session/src/options.rs Lines 754 to 758 in 1500f0f |
|
Oh, the macro calls the field |
26a9ee8 to
a389cd6
Compare
|
Given that this has ABI implications, ignoring it seems even more horribly unsound than its current existence. Someone passing it is likely relying on it, so erroring seems like the correct behavior. |
|
(FWIW I think the nomination should be removed and a Zulip topic or MCP opened instead. T-compiler doesn't really do design discussions or decisions in meetings unless there's a lack of activity elsewhere or it's urgent) |
|
Oh, so why does that label exist then...? |
|
Sometimes we do nominate things for the compiler team triage meeting, like if it's urgent or has a lack of progress. But because of the scale of the team, the triage meeting has a different purpose than other team's meetings. I'm not sure if it is documented anywhere, but it should probably be. |
(It's not a github team, but it is an triagebot ping/notif group, see https://rustc-dev-guide.rust-lang.org/notification-groups/arm.html, invocation is EDIT: also, an MCP for this would probably be good, we can kickoff FCP on the MCP itself. |
|
I filed an MCP: rust-lang/compiler-team#971. |
| } | ||
| if !setter(&mut op, value) { | ||
| match value { | ||
| _ if *type_desc == desc::parse_error => early_dcx.early_fatal( |
There was a problem hiding this comment.
This is quite the hack. I guess a better option would be to extend is_deprecated_and_do_nothing so that it can indicate both "ignored" and "removed"?
This comment has been minimized.
This comment has been minimized.
| pub(crate) use super::*; | ||
| pub(crate) const MAX_THREADS_CAP: usize = 256; | ||
|
|
||
| /// THis is always an error. Used for removed options. |
There was a problem hiding this comment.
| /// THis is always an error. Used for removed options. | |
| /// This is always an error. Used for removed options. |
This comment has been minimized.
This comment has been minimized.
67a79c7 to
69146dd
Compare
This comment has been minimized.
This comment has been minimized.
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This fixes #129893 by removing the offending flag.
The flag has been added in pre-1.0 times (#9617) without much discussion, probably with the intent to mirror
-msoft-floatin C compilers. It never properly mirrored clang though because it only affected the LLVM float ABI setting, not the "soft-float" target feature (the clang flag sets both). It is also blatantly unsound because it affects how float arguments are passed, making it UB to invoke parts of the standard library.The flag got deprecated with Rust 1.83 (released November 2024), and in the year since then, nobody spoke up in #129893 to have it preserved. I think it is time to remove it. I can totally imagine us bringing back a similar flag, properly registered as a target modifier to preserve soundness, but that should come with a coherent design that works for more than one architecture (the flag only does anything on ARM).
Blocked on approval of rust-lang/compiler-team#971.